Business processes are the activities performed by companies, or other entities engaged in business activities, to achieve business goals. Business processes often include information technology (“IT”) related activities related to the storage, management, processing, maintenance of, and access to, data generated, collected and stored in the course of conducting business operations, such as customer records, inventory records, marketing and forecasting data, accounting data and other data related to the operations of the particular business, such as the business rules applied to the processing of such data. Business process outsourcing refers to the delegation of management and operational responsibility for an IT-enabled, or other, business function, or process area, to an external services provider, such as via a long term contractual arrangement. Business process outsourcing may include the outsourcing of some or all of a company's business processes to a third party so as to reduce the costs of implementation, operation, etc. by leveraging the third party's common infrastructure that it provides or otherwise uses to service multiple different customers.
For example, in the health care industry, large health insurance companies may outsource the management and processing of insurance claims filed by members of the health plans operated by those health insurance companies, as well as the storage and maintenance of the records thereof. Third party companies, such as DST Health Solutions, Inc., located in Birmingham, Ala., referred to as a business process outsourcing organization (“BPO”), act as an intermediary receiving and processing claims and storing and maintaining data related thereto, typically subject to one or more service level agreements (“SLA”).
Outsourcing of business processes, however, can create logistical and operational issues for the companies whose processes have been outsourced, referred to as the “outsourcing” company or organization. Ideally, the outsourced business processes integrate seamlessly with those business processes still retained by the outsourcing company. For example, ideally the outsourcing company's management is able to perform analysis and generate reports based on data, or otherwise access and update/modify data, maintained, or processing rules applied, by the BPO, in the same manner in which they could achieve such access, perform such analysis, updates/modifications or generate such reports if the data were still maintained internally by the outsourcing company. In other words, ideally the use of a BPO is transparent to the outsourcing company. However, a BPO's implementation of a business process is often developed independently of the outsourcing company and is often implemented using multiple proprietary or otherwise incompatible architectures which may be different than the outsourcing company's implementation of that process, or otherwise easily integrated with other processes of the outsourcing company. This may be further complicated by the BPO's own use of legacy technologies and haphazard implementation of newer technologies, as well as the need to support the BPO's own internal business processes.
Further, as was noted above, BPO's often undertake the implementation of similar out-sourced business processes for multiple companies/customers for the sake of cost savings. Accordingly, these BPO's often must internally standardize, i.e. leverage, their implementation of a given business process, as well as the supporting data storage architecture, to efficiently serve multiple customers and meet the terms of the SLA's, while being able to provide customized and substantially transparent access, i.e. the appearance of a customer-centric system, to the business process for each of the BPO's customers, as well as support the BPO's own internal business processes used to operate their outsourcing business. This level of technical standardization often results in inconsistencies that force the use of manual compensation processes which increases costs and reduces transparency.
In the particular area of data storage, e.g. the management of data sources and access thereto, maintaining a substantially standardized data storage architecture for all of a given BPO's customers while providing transparent customer-customized access, results in a complicated and often somewhat manually operated system. This is further complicated by the complexity of the BPO's internal architecture which may involve numerous disparate/heterogeneous data sources, including legacy systems, which may have evolved at different rates over time, storing data in different formats and with different requirements. Accessing this data on behalf of a particular customer, for example, may require an operator to manually access the various disparate resources which store the customer's data, manually interpret and aggregate the data and provide the aggregate to the customer. Facilitating the storage of new data and/or updates to the stored data by a particular customer may require the operator to manually translate and segregate the updates to the appropriate data repositories within the BPO's storage architecture.
Where the storage architecture of a BPO consists of homogeneous data sources, a “view” may be used to provide customer specific access to those data sources. In database theory, a view consists of a stored query accessible as a virtual table which is composed of the result set of a query. Unlike ordinary tables (base tables) in a relational database, a view does not form part of the physical schema, i.e. the database's logical and physical structure definition: it is a dynamic, virtual table computed or collated from data in the database. Changing the data in a table alters the data shown in subsequent invocations of the view. Views can provide advantages over tables: Views can represent a subset of the data contained in a table; Views can join and simplify multiple tables into a single virtual table; Views can act as aggregated tables, where the database engine aggregates data (sum, average etc) and presents the calculated results as part of the data; Views can hide the complexity of data, for example a view could appear as Sales2000 or Sales2001, transparently partitioning the actual underlying table; Views take very little space to store, the database contains only the definition of a view, not a copy of all the data it presents; Depending on the SQL engine used, views can provide extra security; and Views can limit the degree of exposure of a table or tables to the outer world.
However, views, as described above, are incapable of providing access to a storage architecture which includes disparate/heterogeneous data sources, including legacy systems, storing data in different formats and with different requirements. In such implementations, automated interfaces may be provided allowing the customer to access their own data but such interfaces are complex and often require that customer specific databases, i.e. replicated databases, be created ahead of time from periodic extractions from the central data sources. These periodically replicated databases create coherency issues such as ensuring that the customer has access to the most up to date information maintained by the BPO and that the BPO has timely access to any updates provided by the customer.